![]() |
Java Database Programming with JDBC
by Pratik Patel Coriolis, The Coriolis Group ISBN: 1576100561 Pub Date: 10/01/96 |
Previous | Table of Contents | Next |
Now that you have seen how to use JDBC drivers, its time we ante up. In this chapter, we jump into the JDBC with an example applet that well build on and derive from through the rest of the book. Our Interactive Query applet will accomplish a number of tasks. It will:
Of course, before we can get to the programming details of the applet, we need to take a step back, review the basics, and put together a plan. I know, plans take time to develop, and you want to get into the good stuff right away. But trust me, well be saving ourselves a lot of trouble later on by figuring out just the right way to get to where we want to go.
Our first step in creating a quality applet is understanding exactly what we need to do. This section covers some applet basics, at a high level. Well begin by discussing the functionality of the Interactive Query applet, and then well explore how to fit the data-aware components contained in the JDBC into the Java applet model. As I said before, every great program starts with a well-thought-out plan, so well work through the steps to create one. If you are familiar with Java, take the time to at least review the following section before moving on to Getting A Handle On The JDBC Essentials. However, if you are unsure about what an applet really is, and why its different from a generic application, you will want to read this section all the way through.
The applet structure has a well-defined flow, and is an event-driven development. Lets begin by defining what we want the SQL query applet to do at a high level. First, we want to connect to a database, which requires some user input: the database we want to connect to, a user name, and, possibly, a password. Next, we want to let the user enter an SQL query, which will then be executed on the connected data source. Finally, we need to retrieve and display the results of the query. Well make this applet as simple as possible (for now), so that you understand the details of using the JDBC API and have a firm grasp of the foundations of making database-aware Java applets.
Our next task is to fill in some of the technical details of our plan. The absolute first thing we need to do, besides setting up the constructors for the various objects we use, is design and layout the user interface. We arent quite to that phase yet (remember, were still in the planning phase), so well defer the design details for a later section of this chapter, The Look of the Applet.
We need to get some preliminary input from the user; we need to have some event handlers to signal the applet that the user has entered some information that needs to be processed, like the SQL query. Finally, we need to clean up when the applet is terminated, like closing the connection to the data source.
Figure 4.1 shows the flow diagram for the applet. As you can see, we do most of our real work in the Select method. The dispatcher is the event handler method, handleEvent(). We use several global objects so that we dont have to pass around globally used objects (and the data contained within). This approach also adds to the overall efficiency; the code shows how to deal with some of the events directly in the event handler.
Figure 4.1 Flow diagram of the Interactive Query applet.
The Applet Four-Step
As indicated in Figure 4.2, Java applets have a distinct life cycle of four basic steps: initialization, execution, termination, and clean up. Its often unnecessary to implement all four, but we can use them to our advantage to make our database-aware applet more robust. Why does an applet have this flow? Applets run inside a Java Virtual Machine (JVM), or Java interpreter, like the one embedded within a Java-enabled Web browser. The interpreter handles the allocation of memory and resources for the applet, thus the applet must live within the context of the JVM. This is a pre-defined specification of the Java environment, designed to control the applets behavior. Note that Java applications do not follow this life-cycle, as they are not bound to run in the context of Java applets. Heres a synopsis of what the four overridable methods, or steps, do in the context of Java applets:
Figure 4.2 An applets life cycle.
As I said earlier, you dont need to have all four steps in your applet. For instance, our simple applet doesnt need the start and stop methods. Because we arent running an animation or any other CPU-consuming process continuously, we arent stealing many precious system cycles. Besides, if you are connected to a database across the Internet and execute a query that takes time to process and download the results from, you may want to check your email instead of staring at the computer while the applet is working. These methods are meant to be overriden, since a minimal default for each method exists; the default depends on the individual intended function of the four methods.
Previous | Table of Contents | Next |